An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

I am trying to add testers to External Tester groups for a couple of our iOS apps and after adding them it shows "No Builds Available". This is despite the app being available to that External Tester group with other people having already installed the latest version of the app which is "Available" and not expired. Can someone please fix this? It is so frustrating the number of times I try and release apps to TestFlight and there's some issue blocking me, completely out of my control and I have to rely on someone at Apple fixing something on this terrible AppStoreConnect system.

Hello, I am looking for guidance on a submission that has been in review for an unusually long time, and to ask whether other developers are seeing the same thing. App: Kids Coloring & Learning Games Apple ID: 6754971485 Platform: iOS Support case: 20000144299546 Timeline: 14 Aug 2026 — submitted, entered Waiting for Review 14–24 Aug — no movement (10 days), never entered In Review 25 Aug — cancelled and resubmitted the identical build ~3 Sept — entered In Review Today — still In Review That is 35 days since first submission and about 17 days in In Review. I have contacted Developer Support and my expedited review request was accepted and confirmed. Despite that, there has been no further movement and no communication. There are no messages in Resolution Center and the review team has not asked me for anything. This is an update to an app already live on the App Store, in the Kids Category with in-app subscriptions. The build itself is unchanged from a version that was previously approved. My questions: Is there a way to find out whether something specific is blocking this review, as opposed to it simply being queued? Are other developers currently seeing extended In Review times, particularly for Kids Category apps with subscriptions? Is there anything further I should do, or is waiting the only option at this point? I would rather fix a problem on my side than keep waiting if something is actually wrong. Any guidance would be appreciated. Thank you.

Hello Apple Developer Community, I am an independent developer and I have reached a point where I genuinely do not understand what the correct path forward is. I have invested a very significant amount of personal time and money into Zivoo. The app has never been released on the App Store. Every time App Review provided feedback, I tried to address it seriously and substantially redesign the product instead of simply resubmitting the same application. The first versions of Zivoo focused on real-time social communication. Later, the app was rejected under Guideline 4.3(b) because Apple considered the experience too similar to existing dating apps. In response, we substantially redesigned the product again. Profile browsing, swipes, likes, skips and mutual-like mechanics were removed. The current Zivoo is focused on language learning and real-time language practice through active conversation rooms, AI-assisted room discovery, entry requests, live conversations, voice/video messages, reactions, shared mini-games and invitations for future practice. The application-specific code, backend, UI system, custom assets, product logic and more than 35 custom animations were developed specifically for Zivoo. We have never purchased a white-label app, cloned another application, purchased an app template or repackaged another developer's product. We do use standard third-party SDKs such as Yandex Mobile Ads, mediation SDKs, Firebase, AppMetrica, Lottie and others. During this process, we may also have made an important mistake. Previous Zivoo submissions used: confident.zivoo, ru.zivoo.social The current submission uses: ru.zivoo.talk All of these Bundle IDs belong to the same Apple Developer Team. Zivoo has never been published on the App Store, and multiple versions of Zivoo have never been publicly distributed at the same time. After previous rejections and major redesigns, we removed previous App Store records. Because the concept had changed significantly, we mistakenly believed that the redesigned product should be submitted under a new App Store record and Bundle ID. This was never intended to bypass App Review or distribute multiple copies of the same app. The current submission has now been rejected under Guideline 4.3(a), stating that it shares a similar binary, metadata and/or concept with apps submitted by us or other developers. The most difficult part of this process is that we are never clearly told what exactly is considered wrong. With each rejection, we receive a broad guideline reference, but not a specific explanation of which code, asset, metadata element, feature or concept triggered the decision. We currently see two possible explanations: Apple's systems may be matching the current submission against our own previous Zivoo submissions under different Bundle IDs. Shared third-party SDK components may be contributing to the binary similarity signal. Our technical analysis shows that standard third-party libraries represent a substantial portion of the measured build. We fully understand that this does not prove that the SDKs caused the rejection. At this point, however, I am afraid to simply make random changes and resubmit again, especially because the latest rejection also includes an Extended Review warning. I am not asking for automatic approval or special treatment. I simply want to understand what Apple actually expects us to fix. Can 4.3(a) be triggered by a developer's own previous submissions under different Bundle IDs, even if none of them were ever released? Can common third-party SDKs contribute to the similarity determination? And if Apple believes our application-specific code, assets or concept are similar to another developer's app, how can we verify or address that? I am prepared to provide client and backend source code, Git history, original design files, dependency information, build details and a live demonstration. If anyone has experienced a similar case, especially after removing previous app records and submitting a substantially redesigned version under a new Bundle ID, I would greatly appreciate hearing how it was resolved. If Apple Staff sees this post, I would be extremely grateful for concrete guidance on what exactly we should do next. Thank you.

Hi everyone, I'm looking for advice from developers who have dealt with Guideline 4.3 in a situation involving a previously terminated Apple Developer account. We have a legitimate travel booking application that was previously submitted to the App Store under our original Apple Developer account. Unfortunately, that developer account was terminated, and despite multiple appeals/support requests, we were unable to have the account restored. We subsequently created a new Apple Developer account and attempted to submit the same legitimate travel application under the new account. The current application has a significantly redesigned UI and UX, but the mobile application is still based on the original React Native codebase. The backend, APIs, travel integrations, booking system, etc. are our existing platform and are not copied from another application. The submission is now being rejected under Guideline 4.3 with wording indicating that the app shares a similar binary, metadata, and/or concept with apps previously submitted by a terminated Apple Developer Program account. My question is specifically about understanding what Apple may be identifying in this situation. Has anyone experienced a similar case where: The same legitimate product was previously submitted under a terminated developer account. The developer then had to submit it from a new account. The new submission was rejected under 4.3 because of its relationship to the previous app/account. If so, were you able to determine whether Apple's concern was primarily: the binary/source-code similarity, the previous developer account association, metadata/assets, or the fact that it was essentially the same product? I'm considering rebuilding the iOS client from React Native to Flutter as a genuinely new implementation while keeping our existing backend/API platform. Before investing significant development time in that rewrite, I'd like to understand whether changing the mobile technology would actually address this type of 4.3 issue, or whether the previous account association can still cause the rejection regardless of the framework. I'd also appreciate any experience with getting a specific answer from App Review about what triggered the 4.3 rejection in cases involving a terminated account. Thanks in advance.

Hi everyone, I would like to ask if anyone else has experienced a longer-than-usual "In Review" phase recently. Here is the timeline for our app, App ID: 6800282515: Submitted for Review: Sep 14 at 05:00 Pacific Time Checked and found status in "In Review": Sep 14 at 19:00 Current Status: Still "In Review" (as of Sep 17, 19:00+) It has been in the "In Review" state for over 3 full days without any updates, rejection notices, or requests for additional info. Has anyone run into a similar issue lately? Is there any recommended way to handle this, or should we just wait a bit longer? Any advice would be greatly appreciated!

A week ago I sent an app for review with 2 platforms (iOS + tvOS). It had a couple IAPs and I attached them to the iOS submission. Then I sent tvOS for review. For my surprise, platforms are reviewed individually and with different timings. Perhaps tvOS / macOS has less released apps than iOS and their queues are smaller. What happened, you guessed it, tvOS got approved and iOS was still queued. Consequence: people on tvOS couldn't buy any of the IAP because they were attached to the iOS submission. Lesson learned: when having more than one platform in review, make sure you change app launch from automatic to manual so you can wait for both being approved and then release them whenever you want.

Hello, Our app (Apple ID 6797897487) is an internal operations tool built under contract for a single business. It was rejected under guideline 4.3(a) on 29 August. We replied in App Store Connect on 31 August and on 10 September, adding that Apple had approved unlisted app distribution for the app on 8 September, but we have not received any response since. What is the recommended next step here? Should we resubmit the same build with the updated information, or wait for a reply to the existing messages? Thank you.

Our app, Roll (Apple ID: 6797953438), has received two Guideline 4.3(a) spam rejections. Our responses have gone unanswered for almost 3 weeks, and then we got an account warning. August 27: First rejection. We replied requesting clarification, explaining the app’s functionality, and supplied a walkthrough video. September 14: After almost three weeks without clarification, we submitted a substantially revised build with new functionality. We included an explanation directly in the App Review notes. September 15: The exact same rejection, still without identifying the issue or addressing our notes to them. This time, it included a warning about account removal for repeated noncompliance. It seems Apple is refusing to read our replies. Instead, they got back to us with the same rejection and a warning. For what? Doing as we were told and writing a reply? Note that thus far, NONE of our replies have even been acknowledged. Has anyone resolved a similar 4.3(a) rejection? What helped you get specific clarification or a call with App Review?

Hello App Review, Our iOS app was rejected under Guideline 5.6 (Developer Code of Conduct). The message states that the app appears to contain features intentionally hidden during review, and that this pattern is commonly associated with fraudulent activity. We want to address this correctly, but the current note does not identify the specific flow, screen, or behavior that was observed. Without that, we cannot investigate the exact issue. Could a member of App Review please follow up in App Store Connect with more concrete detail, or advise what we should check? @WWDR App name: Prime Cedi Loan Apple ID: 6808185084 Version: 1.1.0, Build 2 Guideline: 5.6 We have already replied in Resolution Center and are ready to provide test accounts, a demo video, or a phone call if that would help. Thank you.

Hi, our prediction market app, Even, has been rejected under Guideline 5.3.4. Even is a mobile frontend built on Polymarket’s markets and trading infrastructure. Apple says we have not provided licensing and permission documentation for every country or region selected in App Store Connect. It has also asked us to limit App Store availability and app access to licensed locations. We’ve added geoblocking so users in restricted regions cannot place orders; they can only browse public market information in read-only mode. We also updated our App Store description to explain our relationship with Polymarket and the regional restrictions. We’ve noticed other prediction market apps that appear to be available across many App Store regions with trading enabled. We may not know what licenses or arrangements those developers have, but we’d appreciate help understanding why our submission is being treated differently and what evidence Apple needs from us. For a third-party frontend, does Apple require our own licensing documentation for each region, or could authorization and documentation from the underlying market operator satisfy review? Is read-only access in restricted regions insufficient under Guideline 5.3.4?

Hey Apple Developers! I am about to release my first iOS Application, but I am having a hard time with the app reviews. Here some curiosities I just don't understand. Hopefully you can tell me why the app was rejected and what I have to do in order to make it work... Review A: Apple first responded with: Guideline 2.5.4 - Performance - Software Requirements Due to the usage of Bluetooth Low Energy and the Core Bluetooth framework and Guideline 2.1 - Information Needed The App Tracking Transparency permission request, due to the usage of Ad frameworks. So I created a video in which I explained why I need it and anotherone where the ATT dialog appears. (since I am from germany, I even used a VPN to "simulate" the appearance of the ATT Dialog in the US, since in the EU dialog this looks a bit different. The EU version of it was visible in the initial video I provided. After that (still same request ID) it got rejected because the IAP was missing in the review request, even though it was in there. BLE and ATT wasn't a problem anymore I thought, well may be they've overseen the IAP, so I created a complete new request, uploaded a new (further developed) application. No changes on the IAP, ATT nor BLE parts. Review B: Again this was declined, for the same reasons review A was declined the first time. I explained EXACTLY the same thing, as in review A. The only answer was: We appreciate your efforts to comply with the App Review Guidelines. Please resubmit the app for review in App Store Connect once any necessary adjustments have been made. We look forward to reviewing your resubmitted app. I thought: Well, may be it's not possible to approve an app that was once declined (as mentioned this is my first review) So I created a new review request. Review C: Including a new video for the app itself (I was had developed some progress already) and the BLE video again (to prove the usage of CBPeripheralManager and CBCentralManager) It got decline AGAIN. Reasons: Guideline 2.5.4 - Performance - Software Requirements BLE again Guideline 5.1.2(i) - Legal - Privacy - Data Use and Sharing ATT Problem again. Again, explained where to find it and even provided timestamps for the videos on where to find the ATT. (There were 2 reviews upfront this story without the Ad/ATT part already, that's why I wrote "...5th request") I am very frustrated right now and I have no clue what I am supposed to do here. It might be that I am doing something wrong here (as mentioned, first apple review), but please, let me know what that is!

Hi, our new app Amisoria (App ID 6805385809, Submission ID 95e40745-299b-4467-b9f6-8dd5ca907b02) was submitted Aug 29. On Aug 30 we received a Guideline 2.1 "Information Needed" message; we replied Aug 31 with all eight requested items including a screen recording, and followed up on Sep 3. We also opened Developer Support case 102955409950 on Sep 7. There has been no response of any kind since Aug 30. Could someone from App Review please take a look? The app is a client for a self-hosted AI gateway; a built-in demo mode lets reviewers test it without any server. Thank you.

To the Apple Review and Developer Support Teams, I am writing to request guidance and assistance regarding a persistent rejection my React Native application is facing under Guideline 2.1 - Performance (In-App Purchases). My app has been rejected multiple times with the following specific note: "The In-App Purchase products in the app still exhibited one or more bugs which create a poor user experience. Specifically, the subscription screen failed to load any subscription plans. Review the details and resources below to troubleshoot this issue." The screenshot provided by the review team shows a completely black screen where our paywall options are intended to populate, indicating that the product array is returning completely empty during the review process. The Dilemma: We are completely unable to reproduce this behavior on our end. Everything functions flawlessly within our TestFlight builds across multiple physical test devices and various sandbox tester accounts. On TestFlight, the paywall renders instantly, local pricing fetches immediately via SKProductsRequest, and test transactions process without a single error. Our Current Implementation & Verification: Product Status: All subscription products are explicitly marked as "Waiting for Review" in App Store Connect with one In-App product Rejected for not being attached with a bin but I've since submitted the app once again. All the subscriptions and the in-app product have been actively attached to this specific app submission version. Agreements: The Paid Apps Agreement is active, signed, and fully up to date within our Agreements, Tax, and Banking configurations. Identifiers: We have strictly verified that the hardcoded product identifiers in our React Native codebase match the App Store Connect product IDs exactly. Because this error only occurs within the App Review environment and never in TestFlight or local sandboxes, we are at a loss for how to debug or resolve this issue. Could the App Review team or the Developer Support technical team please clarify if there is a known environment mismatch, storefront routing discrepancy, or specific network configuration (such as IPv6 handling in the review sandbox) that would cause production-ready StoreKit products to return an empty array exclusively to the reviewer? Any direct guidance, logs, or steps on how we can successfully surface our plans to your review team would be deeply appreciated. Review Environment Submission ID: 5a35279c-1621-4972-b6c6-7c1fb202b2f0 Review date: May 20, 2026 Review Device: iPad Air 11-inch (M3) Version reviewed: 1.0.2 (8) Thank you for your time and assistance.

Hello, I’m looking for some advice regarding a TestFlight Beta App Review issue. My app, MyStory, was rejected twice under Guideline 2.1(a) with the same general message: App Review was unable to successfully access all or part of the app. In the first review, Apple specifically asked us to provide a demo account with content demonstrating the app’s functionality. We followed those instructions for Build 3: • Created a dedicated demo account with sample content in all four sections. • Added the username and password under Beta App Review Information. • Added testing instructions. • Replied to App Review with the credentials and instructions. Build 3 was nevertheless rejected again under the same Guideline 2.1(a), without specifying which part of the app was inaccessible. We have tested the app and the demo account ourselves, and everything works as expected on our devices. The app can also be used without an account, and users can create an account directly within the app. We have now replied to App Review asking them to identify the specific screen, step, or functionality they were unable to access. We are currently waiting for a response. Has anyone experienced a similar situation? In particular, I would appreciate advice on how to get a more specific explanation from App Review, or whether there is an appropriate way to escalate the issue if they cannot identify what was inaccessible. I’m also wondering how reliable the 24-hour response timeframe is in practice. It has now been more than a day and a half since I replied to App Review. Should I expect a response within a few days, or can Resolution Center replies sometimes take considerably longer? Thank you.

Hello, I have been experiencing repeated “spam” rejections across several app submissions, including apps that are unrelated to one another, and I would appreciate advice from developers who have encountered a similar situation. I initially developed a sports-themed deckbuilding game and created separate versions based on different sports. Although they share a general concept, each version has its own sport-specific rules, terminology, progression, and gameplay systems. For example, the basketball version uses drafts, while the football/soccer version uses transfers. Three of these sports versions were approved, while three others were rejected as spam. I understand that apps based on a shared concept may require additional clarification, so I explained the differences between them during the review and appeal processes. However, subsequent apps that are completely unrelated to those sports games have also been rejected as spam. This includes: A paid game with a different concept and gameplay A free meeting app with no purchases, subscriptions, or paid content The meeting app was also initially questioned because the review team could not locate a payment mechanism. However, there is no payment mechanism because the app is entirely free. All features are available to every user, and creating an account is optional. My Apple Developer account has been active since 2019, and I had not experienced this pattern before. Because unrelated submissions are now receiving similar rejections, I am concerned that the reviews may be influenced by an account-level classification rather than an individual assessment of each app. I submitted appeals and provided detailed explanations, but I have been waiting for approximately two weeks. The response I received stated: “Due to increased volume, we’re working toward investigating your appeal.” The overall issue has now been ongoing for nearly two months. Has anyone experienced repeated spam rejections affecting otherwise unrelated apps? If so: Were you able to request a broader review of your developer account? Is there a recommended escalation channel beyond the standard appeal process? What supporting information helped demonstrate that the apps were sufficiently different? Is it normal for appeal investigations to take several weeks? I am happy to provide the review team with comparison documents, gameplay videos, detailed feature lists, or any other information needed. I would mainly like to understand the most appropriate way to have each app evaluated based on its own functionality and content. Thank you.

Hi everyone, We submitted a critical update for our iOS app, Hook - AI Rizz Wingman (Apple ID: 6766006483, Bundle ID: com.hook.eden), which contains an essential bug fix for our post-onboarding paywall and subscription flow integration. The build has been stuck in the "Waiting for Review" status for over a week now. Due to the severe impact of the paywall bug on our active users, we also submitted an Expedited Review request, but the status remains completely unchanged and stuck in the pipeline queue without moving to "In Review". Is anyone else experiencing major system delays with the review queue this week? Are there any recommended steps to have a moderator check if this specific build or Apple ID is flagged or stuck in a broken pipeline state, without triggering a re-submission that would lose our place in line? App Details: App Name: Hook - AI Rizz Wingman | Apple ID: 6766006483 | Bundle ID: com.hook.eden | Issue: Paywall & Purchase Flow Critical Hotfix Stuck in Queue. Any insights or moderation checks would be greatly appreciated!

We recently received a 14-day compliance notice regarding Guideline 3.1.2(c) for one of our live apps. We promptly submitted an updated build addressing the subscription flow. However, the build received a Guideline 2.1 (Information Needed) rejection, requesting navigation paths and sandbox reproduction steps for specific In-App Purchase product IDs. Following their instructions to simply reply with the requested information without uploading a new binary, we provided a comprehensive step-by-step PDF navigation guide and submitted our response via App Store Connect yesterday. Because no new binary was uploaded, the submission status remains "Rejected", and our 14-day compliance grace period is expiring in less than 48 hours. We are quite concerned about potential disruption to the live app's availability while waiting for the team to pick up and review our response. Has anyone experienced a similar situation right near the 14-day deadline? Does having an active reply pending review under a "Rejected" status prevent automated removal from sale? Is there any recommended way to flag this urgency to the App Review team beyond the expedited review request (which we already submitted)?

Hello, Our app has been in "Waiting for Review" since September 8 with no status change. It has never moved to "In Review." Steps already taken: Expedited Review Request, approved on September 11, but status did not change Contacted App Review Support for a status update, no response Requested a call, no call has taken place We have received no rejection, no request for additional information, and no messages in Resolution Center. This is time-sensitive: we have a real-world community event on September 19 in Düsseldorf, Germany, tied to this launch. App: KIBAKI: Persian Community Apple ID: 6797615150 Version: 1.0.36 (35) Submission ID: d1f921a3-9001-4ef2-a392-657860c437cd Submitted: September 8, 2026 Could the App Review team please check whether this submission is stuck in the queue? Thank you.

Asking as an individual developer, before building further. Relevant guidelines: 2.5.14, 5.1.1, 5.1.2. Remote support apps are established on the App Store: the user starts a broadcast with RPSystemBroadcastPickerView and a Broadcast Upload Extension, and a human agent views their screen to help them. My design is identical except the frames go to an automated analysis service instead of a human. The results return only to the same user who started the session, to help with their own task on their own device. The design: sessions are started and ended by the user through the system picker, with the standard broadcast indicator visible throughout. Frames are transmitted transiently, never stored, and never seen by any person. There is no remote control or synthetic input of any kind. Captured data is used only for the in session assistance, with explicit consent and privacy policy disclosure per 5.1.2(i). Is swapping the human viewer for an automated analyzer acceptable under the guidelines? And does automated processing of screen content require any disclosures or consent beyond what human viewing requires? Thanks for any guidance.

Xcode version 26.6 (17F113) MyOwnKeyboard-PAD app looks OK using simulator iPad Air 11-inch(M4). It automatically reformats to all orientations using only left and right landscape selected in General, Deployment Info. The submitted app 1.9 (4) had the portrait checked which was an error. I tried to update to version to 1.10 without portrait and upside down, but Validation states it must have all orientations needed. I tried setting all orientations and the simulator cuts off the sides. I am using a new mini M4 with Tahoe 26.6.2 Converted from an older developer mini using Migration Assistant. After conversion Xcode could not find xcspace files and apps locked up. I had to create new apps with different bundles which got conflicted in AppConnects causing rejects. When new versions are submitted, old versions cannot be removed because of submission states. Causing similar binaries, design and scam. I got trapped in the process! I have replied to AppConnect ref. binaries, design and scam. I hope someone can straighten this mess out. The good new is the free MyOwnKeyboard-PHONE analytics look OK with 4,000 impressions and 38 downloads and 172 product page reviews. It's a start! Thank you. Charlie Coupe Designer/Coder 2026sep16